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ABSTRACT 


MITRE has designed and installed a prototype coaxial cable bus com- 
munications system for NASA evaluation at the Johnson Space Center. The 
bus is being used in the Trend Monitoring System to interconnect intelligent 
graphics terminals to a host minicomputer; the terminals and host are con- 
nected to the bus through a microprocessor-based RF modem termed a Bus 
Interface Unit (B1U). This report gives details of the NASA BIU hardware 
and the Carrier Sense Multiple Access Listen-While-Talk protocol used on the 
network. 
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TREND MONITORING SYSTEM (TMS) 
COMMUNICATIONS HARDWARE 
VOLUME II - BUS INTERFACE UNITS 

SECTION I 
INTRODUCTION 


1.0 BACKGROUND 

In 1977» as NASA's Johnson Space Center (JSC) prepared for the 
Operational Flight Tests (OFT) of the Space Shuttle, a need to monitor cer- 
tain thermal parameters of the shuttle in near real time was identified. In 
accordance with the specifications of JSC's Structures and Mechanics Division 
(SMD), the Institutional Data System Division (I DSD) established require- 
ments for and designed an interactive graphics display system to meet the 
identified need. 

The display system, termed the Trend Monitoring System (TMS), is 
structured around a MODCOMP IV/35 host minicomputer, on which data bases 
of thermal parameter values are kept, and six MEGATEK 5000 intelligent 
graphics terminals. The MEGATEKs include a Data General NOVA 3 mini- 
computer, which in the TMS has been programmed to support a variety of 
thermal functions. The terminals and host are linked together by a prototype 
installation of a coaxial cable bus communications system designed by MITR/. 
The bus system was specified by IDSD because of the system's ability to sup- 
port bursty communications requirements at high speed (producing a single 
TMS user plot may require that over 28,000 bytes of data be transferred to 
a graphics terminal in a period of less than 5 seconds). The TMS also pro- 
vides an ideal test-bed for evaluating bus communications systems for further 
application at JSC. The hardware interfaces developed for th .2 computers 
and the supporting software (including some graphics software for the TMS) 
are described in several MITRE reports (Cl 3 > [2], £33 * [4], £53 • [63). Evalua- 
tion of NASA's experience with the bus will be performed in the near future. 


1.1 Overview of Report 

The bus communications system is designed around a coaxial cable 
communications medium to which subscriber devices (either computers or 
terminals or other pieces of equipment) are connected by Bus Interface Units 
(BlUs). The BlUs used at JSC are based on a design which MITRE has used 
in an internal communications system at its home office in Bedford, Massachu- 
setts [7], but with some modifications to support the 16— bit interfaces imple- 
mented to the TMS computers [2]. The JSC bus system operates as a Carrier 
Sense Multiple Access (CSMA) bus using a contention Listen-While-Talk (LWT) 
access protocol. This report describes the CSMA bus and the LWT protocol, 
and also documents the actual structure of the BlUs themselves. The docu- 
ment is intended to provide both background material about the TMS communi- 
cations and information necessary for NASA to maintain the prototype 
equipment. 


SECTION II 


BUS ARCHITECTURE AND SYSTEM OPERATION 
2.0 INTRODUCTION 

Most tranditional bus communications systems rely on Time Division 
Multiple Access (TDMA) techniques, by which time slots are assigned to each 
transmitting subscriber either permanently or at sign-on to the TDMA system . 
This time slotting is efficient when the bus services high-duty-cycle users 
whose traffic intensity does not vary significantly with time, but large numbers 
of low-duty-cycle users or users with high burst data rates can quickly over- 
burden a TDMA system when slots are uniquely assigned to each subscriber. 

Contention protocols have been introduced to bus systems in an effort 
to use the limited bandwidth more effectively. Especially in computer and 
terminal conmunications , the contention techniques can take advantage of the 
"burstiness" of typical user interactions. Given a large subscriber popula- 
tion or bursty users, contention protocols use the law of large numbers and 
provide bandwidth to match the average aggregate data transmission rate of 
the entire population, rather than matching the sum of the peak rates, as in 
more conventional techniques. In the TMS burstiness is expected to be pro- 
nounced, since a single user command of 10 or fewer characters is expected 
to produce a response of up to 25,000 characters with a desired response time 
of less than 5 seconds. This activity will then be followed by think times of 
15 seconds or more. 

Contention systems, as their name implies, allow users to contend for 
use of the medium and to collide during transmissions. As a result, users 
must sense these collisions and retransmit after a pseudo-random delay. 

The following paragraphs describe the overall architecture of the 
NASA bus, the basic system operation, and details of the listen-while-talk 
communications protocol. 


2.1 Bus Architecture 


The NASA TMS bus communications system is an unslotted Carrier 
Sense Multiple Access (CSMA) system employing a contention Listen-While- 
Talk (LWT) protocol. Multiple access means that all subscribers share the 
same digital communications channel, have access to all information carried 
on the channel, and are capable of transmitting to any other subscriber. 
Carrier sense means that no subscriber begins transmitting unless, to the 
best of its knowledge, the channel is not in use. The listen-while-talk proto- 
col means that each subscriber listens to each of its own transmissions for 
at least the maximum propagation delay of the system and aborts the trans- 
mission if a collision with another subscriber's message occurs. The NASA 
system operates at radio frequency (RF) on a coaxial cable system [1] installed 
for the TMS . The center frequency of the carrier is 24.5 MHz. 

When one subscriber has a message for another subscriber, a logical 
(virtual) connection must be established between the subscribers before the 
message can be sent. The "sign-on" protocol described in paragraph 2.2 
below is used to set up the virtual connection. The logical link then applies 
to all messages transmitted by either subscriber until the connection is broken 
by action of one of the subscribers. When a logical link is terminated by one 
party, the other subscriber is notified by means of a special "sign-off" ser- 
vice message. In the NASA bus system, establishment of logical connections 
is handled in the hardware devices which interface subscribers to the bus, 
rather than directly by the subscribers . 

The basic architecture of the NASA bus is shown in Figure 2.1-1. 

A Bus Interface Unit (BIU) connects each subscriber device (MODCOMP or 
MEGATEK, in the TMS system) to both the inbound and outbound cables. 

The BIU accepts data from the subscriber, buffers the data until the channel 
is free, and then transmits the data as one or more addressed packets. The 
BIU also scans each packet on the bus for its own address. If the packet is 
intended for the BIU's subscriber, the BIU reads the complete packet from 
the channel into one of its own buffers , and then clocks the data to the sub- 
scriber with the appropriate protocol and data rate. 
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The cable system is built around Cable Television (CATV) components, 
including coaxial cable, line amplifiers, directional couplers, and taps [lj. 

These components were designed for outdoor installation and should provide 
a highly reliable communications medium for the TMS system. Each Bus 
Interface Unit transmits on an inbound cable and receives on an outbound 
cable. As Figure 2.1-1 shows, the two cables are joined together at the 
headend of the network, but no repeater or other active headend equipment 
is used because all units operate at the same frequency, and the network opera- 
tion described below does not require time slotting of the bus. Using this 
two-cable approach takes advantage of the well-developed reliable unidirec- 
tional CATV components that are commonly available. 

2.2 System Operation 

The following description of the NASA bus system shows broadly how 
BlUs operate and how messages move through the system. The operation is 
to some extent dependent upon the BIU code (which is described more fully 
in [5J), but the outline below is representative of system operation under the 
CSMA LWT protocol. Paragraph 2.3 contains more information on this 
protocol. 

When a BIU is powered up or reset, it performs internal initialization 
of variables, buffers, etc., and prepares itself to receive messages from 
either the subscriber or the network. The TMS host BIU (at the MODCOMP) 
does not seek to make a logical connection with another BIU. A MEGATEK BIU, 
on the other hand, at power-up or when its reset button is pushed, checks to 
see whether its MEGATEK has been bootstrapped, and, if so, asks with 
which BIU a logical connection should be established. Serial terminal BIUs 
(with RS232 interfaces) in the NASA TMS system always ask the operator 
to which other BIU a connection should be made. 

All data received by a BIU from its subscriber device is buffered in 
the BIU until either an end-of-message (EOM) indication is received or until 
the current BIU buffer is filled. The maximum amount of data which can be 


6 


placed into one buffer is 120 bytes; the buffer is preceded by an 8-byte header 
(giving destination, origin, message type, and length) which is described more 
fully in paragraph 2.3. For the MODCOMP and the MEGATEK, the EOM 
indication depends on the computer-BIU DMA protocol (described in [5J)i 
for serial terminals, any control character (ASCII value < hexadecimal 20) 
is considered an EOM. A buffer that is ready for transmission is termed a 
network packet, and is placed on a queue of packets to be sent out on the bus. 

When the B1U is ready to transmit a packet, the BIU reads the "receive 
key" line coming from the RF demodulator. When the receive key is "off", 
no subscriber is currently using the bus; a logic "0" ("on", in this active low 
logic) indicates that the channel is in use. This is the basic carrier sense 
mechanism. When the BIU finds the receive key off, then, the BIU lowers its 
"transmit key" line and begins to transmit the message; lowering the transmit 
key, of course, places a carrier on the bus. Multiple buffers exist in the BIU, 
so that data may still be accepted from the subscriber device while the network 
transmission is in progress. 

2.2.1 Transmission of Packets 

Because the transmitting BIU enables its receiver when it begins to 
send its message, the BIU sees the receive key go on after the round trip 
propagation delay of the cable system, and then begins to receive its own 
transmission. The BIU compares the first 16 bits received against those 
transmitted. If the bits match, the transmitting BIU disables its receiver 
and dedicates itself to transmitting the remainder of the packet, since all 
other subscribers are now waiting. If the test fails, either due to noise 
or the system or to interference caused by another subscriber's keying on 
during the transmission, the BIU disables the transmitter at once, raises 
(turns off) the transmit key signal, and waits a pseudo-random time interval 
before trying again. The pseudo-random internal generator is started with a 
different seed for each BIU. 

The random back-off between retransmissions is required to eliminate 
the possibility that two subscribers continually attempt simultaneous retrans- 
missions. The choice of the delay time uses a (programmed) random number 
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generator in the B1U with a fixed mean of about 400 microseconds. As a sys- 
tem becomes more heavily loaded, collisions between transmissions increase, 
since the probability rises that two subscribers will start a packet trans- 
mission within the end-to-end propagation delay window. 

Note that the transmitting BIU listens to only 2 bytes (16 bits) of its 
own transmission. This corresponds to about 52 microseconds of network 
time at 307.2 Kbps, and is greater than the maximum propagation delay of a 
cv;ble system which is up to about 9 miles in length. This delay is the time 
window in which other subscribers could possibly start transmitting without 
hearing the first BIU’s transmission; if other BlUs do detect the transmission, 
they defer from transmitting their own packets. This operation is the basic 
feature of the "Usten-while-talk' , protocol. 

2.2.2 Reception of Packets 

The reception of messages from other network subscribers is straight- 
forward. At power-up, the receiver of each BIU is enabled. As the BIU 
detects a packet passing on the bus, it compares the destination address of 
the packet (the first 16 bits) with its own address (in some cases, BlUs 
respond to more than one address, as described in paragraph 2.3.5.) If the 
address comparison is successful, subsequent characters from the network 
are buffered by the BIU until the byte count specified in the packet header is 
satisfy. If the comparison fails, the BIU quickly disables its receiver to 
prevent further interrupts from characters of the packet. As long as the 
transmission of the packet continues, the receive key signal stays on; when 
the receive key returns to the off state (meaning that the packet transmission 
is complete), a nonmaskable interrupt of the BIU occurs, at which time the 
BIU re-enables the receiver and awaits reception of the new packet. 

Once a complete packet has been received, it is placed on a queue of 
packets to be delivered to the subscriber. The BIU clocks the data in to the 
subscriber through the parallel or serial interface, depending on the sub- 
scriber, at the subscriber's data rate. As with output packets, multiple 
buffering of received packets is provided so that subsequent packets may be 
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accepted from the network before the first packets have been transferred to 
the subscriber. 

2.3 The Listen-While-Talk Protocol 

This section gives more details about the LWT protocol whose opera- 
tion was described in paragraph 2.2. Five parts of the protocol — packet 
format, error correction, flow control, status, and network addressing — 
are described in the following paragraphs. 

2.3.1 Packet Format 

Figure 2. 3 .1-1 shows the basic packet format for the LWT bus. 

Two-byte fields were chosen for the addresses in the header in order to 
allow full addressing capabilities, convenient use by 16— bit processors, and 
the possible future expansion of message types and addressing schemes 
beyond those implemented presently. The address fields are described in 
paragraph 2.3.5. 

16 bits-»«*l6 bits-><*-8 bits-x-8 bits->«-8 bits-i><*8 bits-s>«-max 960 bits<*<-8 bits-> 
DA QA SN MT RT BC DATA PARITY 

DA = Destination Address 
QA = Originator's Address 
SN = Sequence Number 
MT = Message Type 
RT = Retry Count 

BC = Byte Count (one byte = 8 bits) 

PARITY = Longitudinal Parity Byte 


Figure 2. 3. 1-1. LWT Bus Packet Format 


Present message types on the network include the following: 


1) Data (hexadecimal code 02) - This is the basic packet type, 
and signifies that the following data bytes are data to be passed 
to the subscriber device . 

2) Status (hexadecimal code DB) - This packet type is used to 
transmit 34 bytes of BIU status information plus an 8-byte header 
out onto the network. The structure and usage of the status 
packet are described below. 

3) Sign-on Request (hexadecimal code E2) - This packet repre- 
sents a request from one BIU to another to establish a logical 
link. This packet consists of a header only. 

4) Sign-on Acknowledgement (hexadecimal code DF) - This packet 
is used to reply to a sign-on request when the recipient of the 
request desires to permit the logical link to be established. 

In the NASA system, this packet consists of only a header. 

5) Sign-off (hexadecimal code DE) - This packet, consisting of 
only a header, is transmitted when one BIU wishes to terminate 
its logical link with another BIU. 

The unused message types can be employed in future implementation of other 
protocols or interfaces on the NASA bus. 

The value in the byte count field is one less than the number of bytes 
in the packet. The count includes the length of the header (8 bytes), but net 
the parity byte, and can be in the range from 7 (no data bytes) to 127 (120 
data bytes). A byte count has been used so that special delimiter characters 
can be avoided within a message and any form of data can be transmitted. 

The parity, sequence number, and retry count fields are discussed 
in paragraph 2.3 .2. 
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2.3.2 Error Correction 


The basic LWT protocol offers some amount of error detection because 
a BIU listens to the first part of its own transmission, but a more complete 
end-to-end error detection mechanism is required to permit effective communi- 
cations. On the LWT bus, after a BIU has successfully received a packet, 
the receiving BIU responds with a 1-byte acknowledgement (ACK) which is 
the high-order portion of its network address. This acknowledgement is 
transmitted immediately after the packet is successfully received. In order 
to minimize collisions with the ACK, a BIU always allows a window of approxi- 
mately 100 microseconds following a transmission before it considers the 
channel to be free. The ACK is transmitted during this window. This tech- 
nique was originally proposed by Agrawala [8]. 

2. 3. 2.1 Parity and Retry Count . Each data byte is transmitted on 
the network with an even parity. This parity is checked in hardware as each 
character is received, and the results of the parity check are made available 
to the BIU. 

A longitudinal parity byte is appended to each packet transmitted on 
the network. The byte is calculated in the BIU by performing a running 
exclusive or on the bytes of the header and data as they are transmitted . As 
the message enters the receiving BIU, that BIU calculates the same parity 
byte and then compares the result against the transmitted parity byte. If the 
parity bytes disagree, an ACK is not returned to the sender. If the bytes 
agree, the ACK described above is sent when the packet is completely 
received. 

Regardless of the cause, if a sending BIU receives no ACK or an 
incorrect ACK to a packet it sends, the sending BIU will increment the retry 
count byte in the packet header and immediately retransmit the packet (using 
the normal LWT protocol, of course). When a certain number of retries have 
been made (the number depends on the BIU code and is discussed more fully 
in [5]), the packet is discarded and a count of failed packets is incremented. 
Both the number of retries and the number of failed packets are among the 
information transmitted in status messages (see paragraph 2.3.4). 
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2. 3 .2. 2 Sequence Number . During network operation it is possible 
for a packet to have been correctly sent and received, but the acknowledge- 
ment to have been missed. In such a case, the packet is resent by the trans- 
mitting BIU, but should be rejected as a duplicate by the receiver. For this 
purpose, the fifth byte of the packet header is used as a sequence number 
which cycles from hexadecimal 00 through FF and repeats. In the NASA TMS 
system, since one BIU (at the MODCOMP) transmits to many BIUs and since 
the MODCOMP BIU maintains only a single sequence number (rather than a 
sequence number series for each addressee), the sequence numbers are used 
only for detecting duplicate packets. An extension to the procedure could 
allow detection of missed packets, but would require a higher-level protocol 
to request retransmission of the missed packets. 

2.3*3 Flow Control 

Although the RAM space available in the NASA BIUs permits buffering 
of 20 128-byte packets (total of incoming and outgoing packets), it is possible 
in the case of subscriber malfunction or low speed for a receiving BIU to 
become choked with incoming data. The BIU could be structured so that it 
does not ACK when its buffers are full, but this causes the transmitting BIU 
to retransmit the same packet on the network (thus increasing loading) and 
eventually to discard the packet. Normally, when a receiving BIU’s buffers 
are full, the condition is expected to be temporary, and it is desirable not to 
discard messages. Consequently, the NASA BIUs respond with a special ACK, 
hexadecimal FF, when they are in the full condition. When a sending BIU 
receives this ACK, it waits briefly before retransmitting, so that the com- 
bination of the number of retransmissions and the inter-retransmission gaps 
allows about 2.5 seconds to elapse before packet is discarded. This contrasts 
with an interval of less than 100 milliseconds before a packet is discarded 
when no ACKs at all are being received. 

2.3.4 Status 

In order to provide an effective means of monitoring BIU performance 
and network behavior, status information is collected by each powered-up BIU 
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and transmitted to a special destination address approximately once each 
minute. Table 2. 3.4-1 shows the status fields in the NASA system. In the 
Trend Monitoring System, these status messages are gathered by the host 
computer's BIU and passed to the host, where running totals are kept. The 
method to examine the statistics is described in [6]. 


The statistics are useful in determining network loading and in detecting 
incipient hardware failures of certain types. A high number of noisy trans- 
mits or receives (missing ACKs) may indicate that a BIU modulator or 
demodulator is degrading, for example. A large number of lost packets or 
absence of status message updates from a BIU may imply that a BIU is com- 
pletely inoperative (or merely powered off). Regular review of the statistics 
coupled with a knowledge of BIU usage can provide an indication of components 
needing attention. 


2.3.5 Network Addressing 


Encoded into the PROM of each BIU in the NASA system are one or 
more home addresses to which the BIU responds. The MODCOMP BIU 
responds to both its basic data address (used by MEGATEKs and other sub- 
scriber devices to talk with the MODCOMP) and to the special status message 
destination address (hexadecimal 0000). The MEGATEK BIUs each respond 
to a data address (currently in the range hexadecimal 4100 through 4700) and 
to a booting address (equal to the data address plus hexadecimal 8000). 
Packets sent to the booting address are considered to be parts of a program 
with which the subscriber is to be loaded, while messages sent to the data 
address are considered to be information to be processed by the subscriber 
terminal. More information about the use of these two BIU addresses is 
given in [4]. BIUs for asynchronous serial terminals respond to a single 
address. 


The sixteen-bit address size allows for 65,536 combinations, which 
is a number considerably larger than the several hundred terminals which 
might be connected to a network. The additional addresses can be used for 
various categories of broadcast messages in any extensions of the NASA bus. 
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Table 2. 3 >4-1 • Status Message Fields 


Field 

Number 

Number 
of Bytes 

Description 

1 

2 

Destination address (always 0000 hex) 

2 

2 

Origin address 

3 

1 

Sequence number 

4 

1 

Message type (DB hex) 

5 

1 

Retry count 

6 

1 

Packet length (29 hex) 

7 

2 

Number of packets successfully transmitted and 
ACKed 

8 

2 

Number of retransmissions because of no ACK 
reply to the packet 

9 

2 

Number of collisions 

10 

2 

Number of packets discarded after multiple 
retransmissions 

11 

2 

Number of packets received with a good longitud- 
inal parity byte 

12 

2 

Number of packets received with a bad longitud- 
inal parity byte 

13 

2 

Number of packets not accepted because of lack 
of buffer space to hold the packet 

14 

2 

Number of times a transmission was deferred 
because another BIU was transmitting 

15 

1 

Number of packets queued for transmission (not 
including this status packet) 

16 

1 

Number of packets from the network queued for 
the subscriber 

17 

1 

Network AC I A status register (see paragraph 
3.1.2) 

18 

1 

Device ACIA status register 

19 

1 

PI A parallel port/timer interrupt register 
contents 

20 

1 

High order byte of last destination address 
referenced 

21 

12 

ASCII identification of BIU 


NOTE: Fields 7-14 will not wrap around to zero when they reach FFFF; 
they are cleared after each status packet is sent. 


SECTION III 
BUS INTERFACE UNITS 


3.0 INTRODUCTION 

The Bus Interface Unit (BIU) is composed of a microprocessor-based 
digital logic board, an RF modulator, and an RF demodulator. The components 
are packaged with a power supply in a metal box which is about 10 x 12.5 x 3 
inches in size, and which weighs about 8.8 pounds. The NASA BlUs consume 
about 10 watts of power. 

The RF modulator and demodulator used in the NASA BlUs are not 
described in detail in this report; information about their structure and 
adjustment can be found in [9]. The following discussion deals first with the 
BIU digital logic, which is implemented on a single 7" square plug-in circuit 
board, and then with the BIU chassis. 

3.1 BIU Digital Logic 

Figure 3.1-1 shows a block diagram of the NASA BlU's digital logic. 
The logic supports both an asynchronous serial interface and a parallel inter- 
face, as shown in the diagram, but because of packaging constraints (see 
paragraph 3.2), only one type of interface is supported at a time. The logic 
has been designed to operate with a 307.2 Kbps bus. A complete schematic 
of the NASA LWT BIU is shown in Figure 3.1-2 and a chip layout appears as 
Figure 3*1-3. 

3.1.1 CPU and Memory 

The digital logic employs an NMOS microprocessor, the MOS Tech- 
nology MCS6502A, which was chosen for the design because of its high speed 
and data handling ability, and because its idiosyncrasies were well under 
stood from previous projects. The 6502A is c~> 8-bit CPU with two 8-bit 
index registers, an 8-bit accumulator, and a 256-byte hardware-managed 
stack. The 6502A supports direct addressing, indexed addressing, and 
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Figure 3.1-2 Schematic Diagram of the NASA LWT BIU 
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Figure 3.1-3 Chip Layout of the NASA LWT BIU 





indirect addressing. In the NASA BIUs the CPU is operated using a 1.8432 
MHz crystal-controlled clock. 

Two 1024 x 8 bit EPROM chips are used to provide space for both the 
LWT network firmware and the device-specific firmware. The BIU programs 
themselves are described in [51. The EPROMs are Intel 2708 ultraviolet- 
erasable NMOS memories with a nominal 450 ns access time. Six 1024 x 4 bit 
NMOS static random access memory (RAM) chips provide 3072 bytes of storage 
for program variables and message buffering. The RAMS are Intel 2114 chips 
with a 450 ns access time. 

3.1.2 Peripheral Chips 

Supporting the 6502A are a 16— bit full duplex TTL parallel port with 
handshaking, an RS232-C asynchronous serial port for a subscriber device, 
and an asynchronous port to the bus communications system network. The 
parallel port is implemented using two 6522 Peripheral Interface Adapter 
(PI A) chips for transfer of data, control, and status information between the 
6502 A and the 16— bit parallel interface of either the MODCOMP or the 
MEGATEK. 

Both of the asynchronous ports are based around a 6850 Asynchronous 
Communications Interface Adapter (AC I A) chip, which is used to convert 
between parallel data on the processor bus and serial data sent to or obtain td 
from an external device. The ACIA offloads the microprocessor by independ- 
ently dealing with some of the repetitive overhead functions of serial-to- 
parallel conversion. The 6850 contains a programmable control register 
which can be used to select parity, the asynchronous word length (determined 
by the number of start and stop bits), and the c’ ~>ck divider ratio. 

The clock for both of the AClAs comes from the 14411 Bit Rate Gener- 
ator (BRG) chip, which has an internal oscillator controlled by an external 
1.8432 MHz crystal. The BRG can generate 16 standard frequencies, which 
under program control can be changed by multipliers of 1 , 8, 16, or 64 . In 
the NASA BIUs, the BRG is run in X 64 mode. 
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The network ACIA takes its clock from the 307.2 KHz output of the 
BRG, and this frequency is used to determine the overall bus speed. This 
AClA's communication with the BlU's modems occurs using 8 data bits, even 
parity, 1 start bit, and 1 stop bit. Transmission or reception of a character 
causes a processor interrupt, which is then handled by the network software 
[51. 

The RS232 ACIA takes its clock from any of several outputs of the 
BRG. The particular output desired is selected using an 8-position dual 
inline package (DIP) switch on the digital logic board. In this way, standard 
asynchronous device speeds from 75 bps to 9600 bps can be supported . The 
BRG's clock output is divided by 64 in the ACIA, and device communication 
occurs using 8 data bits, 1 start bit, andl stop bit. Transmission and recep- 
tion of individual characters to the asynchronous subscriber device are 
handled using the 1488 RS232-C line driver chip and the 1489 RS232-C line 
receiver chip in a polled operation. The ACIA is set by the BIU firmware so 
that characters do not cause interrupts of the microprocessor. 

The BIU defines its RS232-C interface signals as if it were a modem. 
The RS232-C signals supported by the BIU, together with their locations on 
a standard 25-pin RS232 connector, are given below. The RS232 standard 
signal designator is shown in parentheses. 

1) D ata Set Ready (CC - Pin 6) - This active low output signal 
indicates the BIU has power and has been initialized. This 
line is strapped to the Clear to Send line on the BIU digital 
board . 

2) Data Terminal Ready (CD - Pin 20) - This active low input 
indicates that the subscriber terminal has power. 

3) Request to Send (CA - Pin 4) - This active low input from the 
subscriber terminal indicates that the device is transmitting 
data. 
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Clear to Send (CB - Pin 5) - This active low output from the 
B1U allows the subscriber terminal to transmit data. The 
Clear to Send line can be controlled by the B1U software. 

5) Transmitted Data (BA - Pin 2) - This line transfers data from 
the subscriber device to the BIU. 

6) Received Data (BB - Pin 3) - This line transfers data from the 
BIU to the subscriber device. 

7) Signal Ground (AB - Pin 7) 

8) Chassis Ground (AA - Pin 1) 

9) Received Line Signal Detector (CF - Pin 8) - This line is 
strapped in the RS232C connector to the Data Set Ready line. 

3.2 BIU Chassis 

This section contains information about the internal components and 
interconnections in the BIU chassis. 

3.2.1 Power Supply and Indicators 

The NASA BIUs include a Boschert Model OL50-001 power supply. 

A CORCOM Model 6J4 line filter supplies 115 VAC from a 115 VAC supply. 

The primary of the transformer is fused at 1.5 amperes. 

On the front panel of the BIU are two lighted rocker switches, one 
of which is a two-position power switch, and the other of which is a momentary 
contact reset switch. Between the switcnes are two indicator lights which are 
illuminated when traffic is being sent on the bus. The red light shines when 
the BIU is receiving any traffic (regardless of the address to which the traffic 
is being sent). The green light shines when the BIU is transmitting on the 
network. The lights are indicators only and do not affect the correct function- 
ing of the BIU . 

These front panel lights are controlled by a simple driver circuit 
implemented on a small printed circuit (PC) board attached to the front of the 
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BIU. Signals for the driver board are taken from the modem circuitry through 
the receive and transmit modem edge connectors; small potentiometers on the 
board control the sensitivity of the driver circuits. Figure 3.2. 1-1 shows a 
complete schematic for the PC board. , 

3.2.2 Wiring Interconnections 

The BIU chassis wiring falls into two categories: (1) wiring used to 
support general functions common to all BIUs (such as power, switches, 
modem connections, etc.), and (2) wiring used to connect the BIU to various 
subscriber devices (computers, terminals, etc.). Most of the interconnections 
are to the chassis edge connector (termed EC) which mates with the BIU 
digital board. Table 3. 2. 2-1 lists power, switch, and indicator light inter- 
connections. The connector identifications which this table uses for the 
front panel PC board and for the BIU switches can be related to the compon- 
ents by Figure 3. 2. 2-1. 

As mentioned in paragraph 3.1, the BIU digital logic is capable of 
supporting either a serial RS232 interface or a parallel interface, but space 
limitations on the back panel of the chassis make it possible to have only one 
connector on any given BIU. For RS232-C subscriber devices, a TRW Cinch 
DB-25S female connector is used, while for the NASA TMS parallel interface, 
a Cinch 50-pin female connector (part number 57-40500) is employed. The 
wiring interconnections for the serial interface are given in Table 3 .2. 2-1 1 
and for the parallel interface in Table 3.2.2-111. Any BIU chassis can be 
converted from one type of connector to the other by performing the appro- 
priate wiring changes. 
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Figure 3. 2. 1-1 Schematic of BIU F 
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Table 3*2. 2-1. Chassis Connections Common to All BlUs 


KEY: 


FROM 


TO 


TM1 

TM4 

TM5 

TM7 

TM9 

TM10 


RM5 

FPf 

FPd, RM6 
EC 109 
ECHO 
EC6l, RM10 


RM1 

RM2 

RM3 

RM4 

RM5 

RM6 

RM8 

RM9 

RM10 


EC111 
EC 105 
EC 108 
FPe, EC103 
EC40 
EC122 
EC112 
ECI07 
EC61 


PS1 (115 VAC) 
PS2 (115 VAC) 
PS3 (-5VDC) 
PS4 (-12VDC) 
PS5 (+12VDC) 
PS6 (return) 
PS 7 (return) 
PS8 (return) 
PS9 (+5VDC) 
PS10 (+5VDC) 

PTJ 

PTB 

PTL 


PTE (black) 

PTC (white) 

EC33 

EC 30 

EC 40 

EC61 

EC61 

EC61 

EC122 

EC122 

PTN 

002 

003 


004 FPa 

005 FPc 


FPb EC 106 

FPg EC6l 


RSI 

RS2 

RS3 

RS4 

RS5 


RS3 

FPi 

RS4 

FPj 

FPh 


TMx = pin x of transmit modem plug-in connection 
RMx = pin x of receive modem plug-in connection 
ECx = pin x of digital logic board edge connector 
FPx * solder point x of PC board for front panel lights 
PSx = pin x of power supply 10-pin connector 
PTx = pin x of CORCOM line filter 
OOx « on/off switch 
RSx = reset swtich 
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Front Panel PC Board 
(Viewed from Tracing Side) 



On/Off Switch 
(Shown in Off Position) 



Reset Switch 
(Momentary Action) 



Figure 3. 2. 2-1 

Connector Identifications for PC Board and Switches 
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Table 3.2.2-11 

Wiring Interconnections for Serial B1U Connector 


Edge Connector Pin 


EC 36 

EC37 

EC38 

EC61 

EC100 

EC 101 


Cinch Connector Pin 


1 (chassis ground) 

6 (strapped to pin 8) 



Table 3.2.2-111 

Wiring Interconnections for TMS Parallel B1U Connector 


Edge Connector Pin 

EC41 
EC42 
EC43 
EC44 
EC49 
EC50 
EC51 
EC56 
EC57 
EC61 
EC67 
EC68 
EC69 
EC70 
EC71 
EC72 
EC73 
EC74 
EC75 
EC76 
EC80 
EC8l 
EC82 
EC83 
EC 84 
EC85 
EC86 
EC87 
EC86 
EC89 
EC118 


Cinch Connector Pin 

9 

8 

7 

6 

19 

18 

17 

12 

24 

25, 46-50 

43 
42 
41 
40 
39 
38 
37 
36 

34 

35 
33 
32 
31 
30 
29 
28 
27 
26 

44 

45 


REFERENCES 


Roman, G. S. The Johnson Space Center Broadband Communications 
System, The MITRE Corporation, MfR-3621 (JSC 014495), 

1 July 1978. 

Brown, J. S. and S. S. Weinrich. Trend Monitoring Sys.em (TMS) 
Communications Hardware - Volume 1 - Computer interfaces^ 

The MITRE Corporation, MTR-4721 (JSC #14b&2), February 1979. 

Brown, ]. S. Trend Monitoring System (TMS) Graphics Software, 
The MITRE Co rporation, MTft-4725 (75^4 7 ^, %r i ri 9 7 9 7" 

Brown, J. S. and M. D. Lenker. Trend Monitorina System (TMS) 
Communi cations Software - Volume 1 - Computer Interfaces , the 
MITRE Corporation, MTR-4723(J5C #14^9^5,' April l97§. 



MITRE Corporation, MTR-4723, (JSC #14793), April.1979. 


Brown , J . S . and M . D . Lenker . Diagnostic Procedures for Trend 
Monitorina System (TMS) Communications, the MtTRE Corporation, 
MTR-4724 (JSC #14794), April 1979. 

Hopkins, G. T. A Bus Communications System , The MITRE Corpora- 
tion, MTR-3515, November 1977. 

Agrawala, A. and R. Bryant and J. Agre. An Analysis of an 
Ethernet-Like Protocol , Proceedings of Computer Networking Symposium, 
Gaithersburg, Md., December 1977. 

Wagner, Paul E. RF Modem for CATV Listen-While-Talk Bus 
Interface Unit, The MITRE Corporation, MTR-3572, April 1978. 


29 



